This is a very very cool feature. Couple of quick questions - I can imagine using this quite a lot - but not read the paper yet...!

1. I often use what I call "responders" - agents with a set of template messages that don't retain history - is it part of the design of this to use the same context, or would using responders help?
2. Is there any overlap with using parallel as part of this too?
   I've got PR on the docs I'd appreciate if you could review. TY!

@lucidprogrammer https://discord.gg/wugKkpaR8e

This is a very very cool feature. Couple of quick questions - I can imagine using this quite a lot - but not read the paper yet...!

1. I often use what I call "responders" - agents with a set of template messages that don't retain history - is it part of the design of this to use the same context, or would using responders help?
2. Is there any overlap with using parallel as part of this too?
   I've got PR on the docs I'd appreciate if you could review. TY!

Yes, "responders" are actually the ideal use case here. Since maker asks the same question multiple times to vote, you want fresh, independent attempts. If an agent keeps history, it might get confused being asked the same thing twice or introduce bias. Stateless responders prevent that perfectly.

Parallel Overlap They solve different problems, I guess. Parallel is for doing different things at once speed/throughput), while Maker is for doing the same thing multiple times (redundancy/correctness). You can use them together, but one doesn't replace the other, thats my intuition on it.

@evalstate you mentioned about a PR to review? Will you send the link, tks

@lucidprogrammer Let me try to respond based on my understanding.

I’ve partially addressed the child history control problem by introducing an explicit parameter:

History / parallel controls supported:

• history_mode (controls child history):

  • scratch: clones start with an empty history
  • fork (default): clones start from the template child history; no merge-back
  • fork_and_merge: clone history is merged back into the template child agent

In all cases, the history is taken from the main instance with the same agent name as the child, not directly from the orchestrator.

I’m still thinking about whether it makes sense to add an option to pull history from the orchestrator when spawning child agents.

You’re absolutely right that, in most cases, you want fresh, independent attempts. The original paper effectively assumes no retained history and passes all necessary information explicitly at call time.

That said, I think there are legitimate cases where some accumulated history can be useful — for example, during a longer reasoning process where you reach a branching point and want to spawn N agents to vote on a decision. In that scenario, sharing a limited, relevant context might make sense.

Regarding the overlap with parallel: I suspect the question isn’t whether one replaces the other (they clearly serve different purposes), but whether the execution machinery can be shared.

From an implementation perspective:

• launching N child tools, whether identical or different,
• waiting for their completion,
• collecting results,

is essentially the same core logic.
What differs is how the results are interpreted and combined (voting vs aggregation vs routing).

So I think there’s a good opportunity to reuse or unify the execution layer, while keeping the result-handling logic separate.